Context-aware component styling in user interfaces of electronic devices

ABSTRACT

The disclosed embodiments provide a system that renders a view component in a user interface of an application on an electronic device. During operation, the system generates, from content describing a view for display in the user interface, a styling path that includes a position of the view component in a content hierarchy of the view. Next, the system selects, by a styling component executing on a processor in the electronic device, a style context for the view component from a collection of style contexts by matching at least a subset of the styling path to an identifier for the style context. The system then uses the style context to render the view component in the view.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of pending U.S. patent applicationSer. No. 14/813,019, filed Jul. 29, 2015, which is herein incorporatedby reference in its entirety.

The subject matter of this application is related to the subject matterin a co-pending non-provisional application by inventors Jay JieBing Yu,Matthew Sivertson, Vinay Kumar, Bojan Beran, Alex Balazs and LuiseFelipe Cabrera, entitled “Common Declaration Representation ofApplication Content and User Interaction Content Processed by a UserExperience Player,” having Ser. No. 14/463,415 and filing date 19 Aug.2014 (Attorney Docket No. 37202/589001; 148432).

The subject matter of this application is also related to the subjectmatter in a co-pending non-provisional application by inventors AnnCatherine Jose, Eugene Krivopaltsev and Jay JieBing Yu, entitled“Content-Driven Orchestration of Multiple Rendering Components in UserInterfaces of Electronic Devices,” having Ser. No. 14/812,934, andfiling date 29 Jul. 2015 (Attorney Docket No. INTU-158753).

The subject matter of this application is also related to the subjectmatter in a co-pending non-provisional application by inventors EugeneKrivopaltsev, Marc Attinasi and Shailesh Soliwal and filed on the sameday as the instant application, entitled “Metadata-Driven Binding ofPlatform-Agnostic Content to Platform-Specific User-Interface Elements,”having Ser. No. 14/813,013 and filing date 29 Jul. 2015 (Attorney DocketNo. INTU-158760).

BACKGROUND Related Art

The disclosed embodiments relate to user interfaces on electronicdevices. More specifically, the disclosed embodiments relate totechniques for performing context-aware component styling in userinterfaces of electronic devices.

A user typically interacts with an electronic device, such as a personalcomputer, laptop computer, tablet computer, mobile phone, digital mediareceiver, and/or portable media player, by providing input to andreceiving output from the electronic device through various input andoutput mechanisms. For example, the user may enter input into a laptopcomputer using a keyboard, mouse, and/or touchpad and receive outputfrom the laptop computer via a display screen and/or speakers.

Applications on the electronic device may provide user interfaces (UIs)that facilitate interaction between the user and the electronic device.In addition, the UIs may be tailored to the input/output (I/O) devicesand/or form factor of the electronic device. For example, a graphicaluser interface (GUI) of an application on a tablet computer may provideUI components such as windows, menus, icons, checkboxes, text boxes,and/or radio buttons. These UI components may be displayed to the userthrough a touchscreen of the tablet computer. In turn, the touchscreenmay allow the user to manipulate the UI components using gestures suchas swiping, zooming, and/or tapping. Because the tablet computer maylack a physical keyboard, the touchscreen may also provide a virtualkeyboard that allows the user to enter alphanumeric input into thetablet computer.

Usability is an important consideration in designing user interfaces. Inparticular, usability considerations may include: the efficiency withwhich tasks are accomplished through the UI; the user's ability to learnand master the operation of the UI; and/or the availability of feedback,help, documentation, and/or status information within the UI. Forexample, the user may accomplish tasks more easily and quickly if UIelements are arranged and displayed in a meaningful way within the UI.Consequently, user satisfaction with an application on an electronicdevice may be highly influenced by characteristics of the user interfaceprovided by the application and/or the user's ability to interact withthe user interface through I/O devices of the electronic device.

BRIEF SUMMARY

As variations in the form factors, platforms, and technologies ofelectronic devices continue to increase, applications may be required toadapt to the variations. For example, different versions of anapplication may be released to support execution on differentprocessors, input/output (I/O) devices, operating systems, screen sizes,and/or web browsers.

When an application is updated to support new features, functionality,platforms, form factors, or technologies, portions of the application'suser interface may be provided by platform-specific renderingcomponents. For example, the application may include a web viewrendering component that embeds web pages within screens of the userinterface, as well as one or more native rendering components that usevarious technologies (e.g., programming languages, libraries, hardwarecomponents, etc.) to natively render user-interface components in theuser interface.

To reduce overhead associated with updating the user interface of theapplication, content used to render the interface may be decoupled fromthe platform-specific rendering components used to perform therendering. For example, a view in the user interface may be describedusing structured data such as a JavaScript Object Notation (JSON)object. In turn, the structured data may be used by rendering componentsimplemented on different platforms to render the same view.

View components in a given view may further be rendered according to thepositions of the view components in a content hierarchy of the view. Toselect a style context for a view component in the view, contentdescribing the view is used to generate a styling path for the viewcomponent that includes the position of the view component in thecontent hierarchy. Next, a style context is selected for the viewcomponent based on a partial or complete match of the styling path withan identifier for the style context. The style context is then used torender the view component. Because the style context is selected basedon configurable metadata describing the view and/or available stylecontexts for the view, styling of the component may be performed in adynamic, flexible manner instead of through hardcoding of styles intothe user interface of the application.

The disclosed embodiments provide a system that renders a view componentin a user interface of an application on an electronic device. Duringoperation, the system generates, from content describing a view fordisplay in the user interface, a styling path that includes a positionof the view component in a content hierarchy of the view. Next, thesystem selects, by a styling component executing on a processor in theelectronic device, a style context for the view component from acollection of style contexts by matching at least a subset of thestyling path to an identifier for the style context. The system thenuses the style context to render the view component in the view.

In some embodiments, generating the styling path for the view componentincludes appending one or more layers of the content hierarchy betweenthe view component and a top of the content hierarchy to the stylingpath.

In some embodiments, matching one or more portions of the styling pathto the identifier for the style context includes searching thecollection of style contexts for the identifier that exactly matches thestyling path, and when the collection does not include the identifierthat exactly matches the styling path, iteratively removing one or moreportions of the styling path until a remainder of the styling path thatmatches the identifier is found.

In some embodiments, iteratively removing one or more portions of thestyling path includes iteratively removing the one or more portions froma middle of the styling path until the styling path contains only abeginning and an end.

In some embodiments, iteratively removing one or more portions of thestyling path further includes removing the beginning from an entirety ofthe styling path to produce the remainder, and subsequently removing theone or more portions from the middle of the remainder to produce one ormore variations of the remainder.

In some embodiments, iteratively removing one or more portions of thestyling path further includes removing the beginning from the remainderof the styling path to produce a variation of the remainder of thestyling path.

In some embodiments, iteratively removing one or more portions of thestyling path further includes removing all portions of the styling pathexcept for the end.

In some embodiments, matching one or more portions of the styling pathto the identifier for the style context further includes matching theone or more portions of the styling path to a wildcard pattern.

In some embodiments, the style context includes an alignment, a font, acolor, a margin, and/or a size.

In some embodiments, the content hierarchy includes a view, a field, acollection, an asset, a label, and a value.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a schematic of a system in accordance with the disclosedembodiments.

FIG. 2 shows a system for rendering a view component in a user interfaceof an application on an electronic device in accordance with thedisclosed embodiments.

FIG. 3 shows a flowchart illustrating the process of rendering a viewcomponent in a user interface of an application on an electronic devicein accordance with the disclosed embodiments.

FIG. 4 shows a flowchart illustrating the exemplary process ofiteratively removing one or more portions of a styling path for a viewcomponent in accordance with the disclosed embodiments.

FIG. 5 shows a computer system in accordance with the disclosedembodiments.

In the figures, like reference numerals refer to the same figureelements.

DETAILED DESCRIPTION

The following description is presented to enable any person skilled inthe art to make and use the embodiments, and is provided in the contextof a particular application and its requirements. Various modificationsto the disclosed embodiments will be readily apparent to those skilledin the art, and the general principles defined herein may be applied toother embodiments and applications without departing from the spirit andscope of the present disclosure. Thus, the present invention is notlimited to the embodiments shown, but is to be accorded the widest scopeconsistent with the principles and features disclosed herein.

As variations in the form factors, platforms, and technologies ofelectronic devices continue to increase, applications may be required toadapt to the variations. For example, different versions of anapplication may be released to support execution on differentprocessors, input/output (I/O) devices, operating systems, screen sizes,and/or web browsers.

When an application is updated to support new features, functionality,platforms, form factors, or technologies, portions of the application'suser interface may be provided by platform-specific renderingcomponents. For example, the application may include a web viewrendering component that embeds web pages within screens of the userinterface, as well as one or more native rendering components that usevarious technologies (e.g., programming languages, libraries, hardwarecomponents, etc.) to natively render user-interface components in theuser interface.

To reduce overhead associated with updating the user interface of theapplication, content used to render the interface may be decoupled fromthe platform-specific rendering components used to perform therendering. For example, a view in the user interface may be describedusing structured data such as a JavaScript Object Notation (JSON)object. In turn, the structured data may be used by rendering componentsimplemented on different platforms to render the same view.

View components in a given view may further be rendered according to thepositions of the view components in a content hierarchy of the view. Toselect a style context for a view component in the view, contentdescribing the view is used to generate a styling path for the viewcomponent that includes the position of the view component in thecontent hierarchy. Next, a style context is selected for the viewcomponent based on a partial or complete match of the styling path withan identifier for the style context. The style context is then used torender the view component. Because the style context is selected basedon configurable metadata describing the view and/or available stylecontexts for the view, styling of the component may be performed in adynamic, flexible manner instead of through hardcoding of styles intothe user interface of the application.

The disclosed embodiments provide a method and system for facilitatinguse of an application on an electronic device. As shown in FIG. 1, anapplication 110 may reside on an electronic device 104 such as a mobilephone, personal computer, laptop computer, tablet computer, personaldigital assistant, navigation system, digital camera, smart watch,and/or portable media player. For example, application 110 may bedownloaded from an online application distribution platform, website,and/or server (e.g., server 102) and installed locally on electronicdevice 104. Alternatively, application 110 may be a web application thatis loaded in a web browser of electronic device 104.

Application 110 may perform a set of tasks for a user of electronicdevice 104. For example, application 110 may allow the user to browsewebsites, send and receive emails, access and/or organize digital media,create and edit documents, play a game, use mapping and/or navigationservices, file taxes, and/or manage personal finances.

During use of application 110, electronic device 104 may use a networkconnection to obtain data 122 and/or content associated with application110 from a server 102 and transmit data from application 110 to server102. For example, electronic device 104 may use a wired, wireless and/orcellular network to send and receive emails, financial information,digital media, game play information, and/or other data 122 or contentused by application 110 with server 102. As a result, application 110may execute using a client-server model.

In addition, interaction between the user and application 110 may beenabled by a user interface 120. For example, user interface 120 may bea graphical user interface (GUI) that displays text, images, documents,menus, icons, thumbnails, form fields, data, buttons, and/or otheruser-interface elements to the user. The GUI may also accept user input(e.g., gestures, keyboard presses, etc.) that is used to manipulateand/or update the elements. In other words, user interface 120 may be amechanism for displaying or formatting data 122 or content associatedwith application 110 for use on electronic device 104.

In one or more embodiments, a rendering apparatus 106 in application 110generates user interface 120 using content obtained from server 102. Forexample, rendering apparatus 106 may obtain the content as one or moreExtensible Markup Language (XML) documents, JavaScript Object Notation(JSON) objects, and/or other types of structured, platform-agnosticdata. The content may describe a set of views, a navigation flowassociated with the views, a set of data elements, and/or a data modelfor the data elements. The described views may specify the text, images,and/or user-interface elements to be included in screens of userinterface 120. The described navigation flow may specify the order inwhich screens of user interface 120 are to be displayed, such as alinear or non-linear flow through screens of user interface 120 that isbased on a state of the application and/or data entered into theapplication by the user. The described data elements may include thenames of the data elements, as well as any values of the data elementsentered by the user and/or obtained from an external source (e.g., taxforms, public records, emails, etc.). The described data model mayspecify the data types of the data elements, such as text, Boolean,enumerated, numeric, date, currency, and/or other data types that may bespecific to the application.

Rendering apparatus 106 may then use natively executing user-interfacecomponents to render one or more views or screens of user interface 120specified in the structured data. In addition, rendering of userinterface 120 may vary with the platform and/or type of electronicdevice 104. For example, rendering apparatus 106 may tailor the layoutof the views in user interface 120 to the dimensions, orientation (e.g.,portrait, landscape, etc.), form factor, and/or input/output (I/O)devices of electronic device 104.

Such decoupling of user-interface content from the platform in which thecontent is rendered may allow updates to user interface 120 to bedeployed without changing the source code used to execute theapplication. For example, a designer or developer may upload a newversion of the content to server 102. Once the new version of content isavailable in server 102, server 102 may provide the new version torendering apparatus 106, and rendering apparatus 106 may generate one ormore views in user interface 120 from the new version instead ofprevious versions of the content. Platform-independent rendering ofcontent in applications (e.g., application 110) is described further ina co-pending non-provisional application by inventors Jay JieBing Yu,Matthew Sivertson, Vinay Kumar, Bojan Beran, Alex Balazs and LuiseFelipe Cabrera, entitled “Common Declaration Representation ofApplication Content and User Interaction Content Processed by a UserExperience Player,” having Ser. No. 14/463,415 and filing date 19 Aug.2014 (Attorney Docket No. 37202/589001; 148432), which is incorporatedherein by reference.

Data 122 collected through user interface 120 may then be used by aprocessing apparatus 108 in application 110 to perform one or more tasksfor the user. For example, processing apparatus 108 may validate data122, format data 122, use data 122 entered by the user to update a stateof application 110, use data 122 to generate additional data or files,and/or commit data 122 to storage on electronic device 104 and/or server102.

In one or more embodiments, rendering apparatus 106 is provided bymultiple rendering components that are implemented using differenttechnologies. For example, application 110 may be a tax-preparationapplication that executes on a mobile device such as a mobile phone,tablet computer, and/or portable media player. New versions ofapplication 110 may be released yearly to accommodate new features,modes of operation, and/or changes in tax code or technology. Asportions of application 110 are added or updated, different renderingcomponents may be included in application 110 to support the renderingof user-interface views or components in those portions. As a result,user interface 120 may be provided by rendering components associatedwith early versions of application 110, widgets added to provide newfeatures to application 110, third-party widgets by third-partydevelopers, rendering components to support platform-specific executionof application 110, and/or web view rendering components that renderembedded web pages within user interface 120.

Rendering apparatus 106 may also include an orchestrator thatcoordinates the rendering of views in user interface 120 by a set ofrendering components. The orchestrator may use content from server 102and/or other metadata to select a rendering component to be used inrendering a view represented by the content. The rendering component mayuse the content to render the second view, and the orchestrator and/oranother component of rendering apparatus 106 may display the view inuser interface 120. Orchestration of rendering components in userinterfaces is described in a co-pending non-provisional application byinventors Ann Catherine Jose, Eugene Krivopaltsev and Jay JieBing Yu,entitled “Content-Driven Orchestration of Multiple Rendering Componentsin User Interfaces of Electronic Devices,” having Ser. No. 14/812,934,and filing date 29 Jul. 2015 (Attorney Docket No. INTU-158753), which isincorporated herein by reference.

To further decouple configuration of user interface 120 from theoperation of the rendering components, application 110 may use metadatato customize rendering of views in user interface 120 by platform, formfactor, orientation, and/or other attributes associated with electronicdevice 104 without requiring changes to the implementation of therendering components. A view builder in each rendering component may usea number of metadata definitions to render a view from platform-agnosticcontent describing the view. The view builder may apply mappings and/orrules from the metadata definitions to platform-agnostic view componentsin the view to obtain attribute-specific types that are based on one ormore attributes (e.g., form factor, orientation, etc.) of the electronicdevice, as well as platform-specific user-interface elements thatimplement the attribute-specific types on the platform of the electronicdevice. Metadata-driven bindings of platform-agnostic content toplatform-specific user-interface elements is described in a co-pendingnon-provisional application by inventors Eugene Krivopaltsev, MarcAttinasi and Shailesh Soliwal and filed on the same day as the instantapplication, entitled “Metadata-Driven Binding of Platform-AgnosticContent to Platform-Specific User-Interface Elements,” having Ser. No.14/813,013 and filing date 29 Jul. 2015 (Attorney Docket No.INTU-158760), which is incorporated herein by reference.

Application 110 may additionally perform dynamic, context-aware stylingof view components in the views of user interface 120. As shown in FIG.2, a styling component 202 may use a styling path 204 for a viewcomponent (e.g., view component 1 212, view component x 214) to select astyle context (e.g., style context 1 220, style context z 222) for usein rendering of the view component within a view of a user interface.Styling component 202 may execute within a rendering apparatus of anapplication on an electronic device, such as rendering apparatus 106 ofFIG. 1. For example, styling component 202 may be a part of aplatform-specific rendering component that renders the view in the userinterface (e.g., user interface 120 of FIG. 1) of the application fromplatform-agnostic content 210 that describes the view, such as a JSONrepresentation of the view.

First, styling component 202 may generate styling path 204 to include aposition of the view component in a content hierarchy of the view. Thecontent hierarchy may be specified in content 210 based on layers ofencapsulation among view components in the view. For example, content216 may include a list of view components (e.g., view component 1 212,view component x 214) in view 208. Each view component may be defined byan identifier, a type (e.g., view, text, collection, field, form field,summary, choice, asset, label, etc.), a value, and/or other parametersrelated to the appearance or use of the view component. A view componentthat is higher in the content hierarchy, such as an asset, mayencapsulate components that are lower in the content hierarchy, such asa label of the asset.

As shown in FIG. 2, styling path 204 for the view component includes anumber of layers (e.g., layer 1 216, layer y 218) of encapsulation. Eachlayer may separate the view component from the top of the contenthierarchy. For example, each layer may represent a different type ofview component that encapsulates the view component, either directly orindirectly. As a result, styling component 202 may generate styling path204 by appending one or more layers of the content hierarchy between theview component and the top of the content hierarchy to styling path 204.

For example, content 210 may include the following JSON representation:

{ “asset”: { “id”: “yes.no.question.fields”, “type”: “collection”,“values”: [ “asset”: { “id”: “yes.no.question.question-11”, “binding”:“returns.IRS1040.ueData.ACA.HasInsuranceNow”, “type”: “choice”, “label”:{ “asset”: { “id”: “yes.no.question.label.text-31”, “type”: “text”,“value”: “One more thing: do you all have health insurance now?”,“accessibility”: “One more thing: do you all have health insurance now?”} }, “choices”: [ { “id”: “yes.no.question.choices.yes-41”, “label”: {“asset”: { “id”: “yes.no.question.choices-Yes-Label-51”, “type”: “text”,“value”: “All of us have health insurance”, “accessibility”: “All of ushave health insurance” } ...

The JSON representation may describe a set of view components arrangedwithin the content hierarchy of the view. The top of the contenthierarchy may include a view component with an “id” of“yes.no.question.fields” and a “type” of “collection.” The “collection”view component may encapsulate a view component with a “type” of“choice” and an “id” of “yes.no.question.question-11.” The “choice” viewcomponent may include a “label” that is defined by an “asset” with an“id” of “yes.no.question.label.text-31,” a “type” of “text,” a “value”of “One more thing: do you all have health insurance now?” and an“accessibility” of “One more thing: do you all have health insurancenow?”

The “choice” view component may also include another view component witha “type” of “choices.” The “choices” view component may encapsulatemultiple possible selection choices within the “choice” view component,including a first choice with an “id” of“yes.no.question.choices.yes-41.” The first choice may have a “label”that encapsulates an “asset” with an “id” of“yes.no.question.choices-Yes-Label-51,” a “type” of “text,” a “value” of“All of us have health insurance,” and an “accessibility” of “All of ushave health insurance.”

The JSON representation may thus be used to render a view that, at thehighest layer of the content hierarchy (e.g., the top of the view),displays a title containing the text “One more thing: do you all havehealth insurance now?” Below the title, the first choice may bedisplayed as a radio button and/or other type of user-interface elementwith a label containing the text “All of us have health insurance.”Additional choices may also be shown below the first choice based onsubsequent descriptions of view components in the view from the JSONrepresentation.

In turn, the styling path of the first choice (e.g.,“yes.no.question.choices-Yes-Label-51”) in the view may include thefollowing:

-   -   collection.choice.choices.fieldTitle.text.regularText        Within the styling path, layers of the content hierarchy may be        separated by “.” The styling path may be created by appending,        in order, the types of view components from the top of the        content hierarchy to the first choice. The styling path may        begin with the topmost “collection” view component and continue        with the “choice” view component and the “choices” view        component. Next, “fieldTitle” may be added to the styling path        to represent the “label” that follows “choices” in the JSON        representation. The “fieldTitle” type is followed by “text,”        which represents the first choice of        “yes.no.question.choices-Yes-Label-51” encapsulated in “label.”        Finally, “text” is followed by “regularText” to indicate that        text in the last view component should be rendered in a regular        style instead of a bold/emphasized style or a hyperlink style.

Next, styling component 202 may select a style context for the viewcomponent by matching at least a subset of styling path 204 to anidentifier 206 for a style context from a collection 208 of stylecontexts (e.g., style context 1 220, style context z 222). As with otherconfigurable aspects of the user interface, collection 208 may beobtained as platform-agnostic structured data. For example, collection208 may be provided in a property list, XML, document, JSON file, and/orother structured document. Within collection 208, each style context mayinclude style attributes such as an alignment, a font, a color (e.g.,text color, background color, etc.), a margin, and/or a size (e.g., fontsize, dimension, padding size, margin size, column size, etc.).

Style contexts in collection 208 may represent a set of “ideal” stylesfor various styling paths that can be found in views of the userinterface. For example, the style contexts may be created by designersor developers of the application to maintain a uniform user experienceacross the user interface of the application. However, because renderinghierarchies of views in the user interface may be too long or complexfor all possible styling paths to be enumerated in collection 208, stylecontexts in collection 208 may be selected for view components in a waythat provides a “best possible” match between the style contexts and thestyling paths of the view components.

During selection of a style context for the view component, stylingcomponent 202 may initially search collection 208 for an exact matchbetween an identifier (e.g., identifier 206) in collection 208 andstyling path 204. If iterative the styling path does not exactly matchan identifier in collection 208, the styling path may be matched to awildcard pattern representing a style context instead of an exactidentifier for the style context. If the styling path does not match awildcard pattern, styling component 202 may iteratively remove one ormore portions of styling path 204 until a remainder of styling path 204that matches identifier 206 and/or a wildcard pattern is found.

After the style context is selected for the view component, stylingcomponent 202 and/or another component of the application may use thestyle context to render the view component. The component may also storea mapping of the styling path to the style context so that subsequentstyling requests for view components with the same styling path can bematched to the same style context without performing the style-selectionprocess for the view components. Such mapping of styling paths toresolved style contexts may thus reduce the processing associated withstyling of various components in content 210.

Continuing with the above example, the styling path of“collection.choice.choices.fieldTitle.text.regularText” may be matchedto a style context in the following manner. Collection 208 may initiallybe searched for a style context with an identifier that matches theentirety of the styling path. If no such style context can be found, oneor more portions of the styling path may be iteratively removed until aremainder of the styling path that matches an identifier in collection208 is found. In addition, iterative removal of portions of the stylingpath may be performed in way that generates variations of the remainderof the styling path in a certain order, so that the first style contextwith an identifier that matches an iteratively generated variation ofthe remainder is used to render the view component.

In a first round of iterations, one or more portions may be removed fromthe middle of the styling path until the styling path contains only abeginning and an end. Variations of the remainder of the styling path inthe first round of iterations may be generated in the followingexemplary order:

-   -   collection.choice.choices.fieldTitle.text.regularText    -   collection.choice.choices.text.regularText    -   collection.choice.text.regularText    -   collection.choice.regularText    -   collection.regularText        Other variations that involve the removal of the middle portions        of the styling path may also be included in the first round of        iterations.

The first round of iterations may be followed by a second round ofiterations in which the beginning is removed from the styling path, andone or more portions are subsequently removed from the remainder of thestyling path to generate variations on the remainder of the stylingpath. The second round of iterations may include the following exemplaryorder of variations on the remainder of the styling path:

-   -   choice.choices.fieldTitle.text.regularText    -   choice.choices.text.regularText    -   choice.text.regularText    -   choice.regularText

The second round of iterations may be recursively applied to a graduallydiminishing remainder of the styling path until only the end of thestyling path remains. Recursive application of the second round ofiterations may produce the following exemplary order of variations onthe remainder of the styling path:

choices.fieldTitle.text.regularText

-   -   choices.fieldTitle.regularText    -   choices.regularText    -   fieldTitle.text.regularText    -   fieldTitle.regularText    -   regularText

Iterative removal of portions of the styling path may thus be conductedto find the closest possible match between the styling path and a stylecontext in collection 208. For example, the iterations described abovemay result in the matching of the styling path to the followingstructured representation of a style context:

<key>choice.choices.fieldTitle.text.regularText</key> <dict><key>UILabel</key> <dict> <key>TextColor</key> <string>#34b8f4</string><key>NumberOfLines</key> <integer>0</integer> <key>TextAlignment</key><string>NSTextAlignmentCenter</string> <key>font</key> <dict><key>Family</key> <string>Avenir-Light</string> <key>Size</key><integer>24</integer> </dict> </dict> </dict>The structured representation may indicate an exact match of the stylecontext with the first value produced in the second round of iterations,or “choice.choices.fieldTitle.text.regularText.” The structuredrepresentation may also specify a number of styling attributes under a“UILabel” sub-context, including attributes for “TextColor,”“NumberOfLines,” “TextAlignment,” “NSTextAlignmentCenter,” and “font.”The “font” styling attribute may additionally include sub-attributes of“Family” and “Size.” Consequently, the structured representation may beused to render text in the view component using a certain color (e.g.,“#34b8f4”), number of lines (e.g., “0”), text alignment (e.g.,“NSTextAlignmentCenter”), font family (e.g., “Avenir-Light”), and fontsize (e.g., “24”).

One or more portions of the styling path may also be matched to awildcard pattern instead of an exact identifier for the style context.For example, the “collection.choice.choices.fieldTitle.text.regularText”styling path may be matched to wildcard patterns such as“collection.choice.*.regularText,” “collection.*.text.regularText,”and/or “collection.*.regularText.” Such wildcard-based matching of thestyling path to the style context may be performed if the entire stylingpath cannot be matched to an identifier for a style context. If thestyling path fails to match one or more wildcard patterns, one or moreportions of the styling path may be iteratively removed until aremainder of the styling path matches the identifier and/or a wildcardpattern.

FIG. 3 shows a flowchart illustrating the process of rendering a viewcomponent in a user interface of an application on an electronic devicein accordance with the disclosed embodiments. In one or moreembodiments, one or more of the steps may be omitted, repeated, and/orperformed in a different order. Accordingly, the specific arrangement ofsteps shown in FIG. 3 should not be construed as limiting the scope ofthe embodiments.

Initially, a styling path that includes a position of a view componentin a content hierarchy of a view for display in the user interface isgenerated from content describing the view (operation 302). The stylingpath may be generated by appending one or more layers of the contenthierarchy between the view component and a top of the content hierarchyto the styling path. For example, the styling path may specify the typesof all layers in the content hierarchy between the top and the viewcomponent.

Next, a style context for the view component is selected from acollection of style contexts by matching some or all of the styling pathto an identifier for the style context (operation 304). To match atleast a subset of the styling path to the identifier for the stylecontext, the collection of style contexts may first be searched for anidentifier that exactly matches the styling path. When the collectiondoes not include the identifier that exactly matches the styling path,the styling path may be matched to a wildcard pattern instead of anexact identifier for the style context. If the styling path does notmatch any wildcard patterns, one or more portions of the styling pathmay be iteratively removed until a remainder of the styling path thatmatches the identifier and/or a wildcard pattern is found, as describedin further detail below with respect to FIG. 4.

Finally, the style context is used to render the view component in theview (operation 306). For example, style attributes in the style contextmay be passed as configuration parameters to a platform-specificuser-interface component that implements the view component on aplatform of the electronic device. The configuration parameters may beused to adjust the appearance and/or behavior of the platform-specificuser-interface component during instantiation of the platform-specificuser-interface component.

FIG. 4 shows a flowchart illustrating the exemplary process ofiteratively removing one or more portions of a styling path for a viewcomponent in accordance with the disclosed embodiments. In one or moreembodiments, one or more of the steps may be omitted, repeated, and/orperformed in a different order. Accordingly, the specific arrangement ofsteps shown in FIG. 4 should not be construed as limiting the scope ofthe embodiments.

First, one or more portions are removed from the middle of the stylingpath until the styling path contains only a beginning and an end(operation 402). Next, the beginning is removed from the styling path(operation 404), and one or more portions from the middle of theremainder of the styling path may iteratively be removed (operation 406)to produce one or more variations of the remainder. Operations 404 and406 may recursively be applied to the styling path, so that the stylingpath is shortened from the beginning one layer at a time, and eachshortening from the beginning is followed by the removal of additionallayers from the middle of the remaining portions of the remainder.Finally, all portions of the styling path are removed except for the end(operation 408). The process may be discontinued once a variation on theremainder of the styling path that matches an identifier and/or awildcard pattern for a style context is generated.

FIG. 5 shows a computer system 500 in accordance with an embodiment.Computer system 500 may correspond to an apparatus that includes aprocessor 502, memory 504, storage 506, and/or other components found inelectronic computing devices. Processor 502 may support parallelprocessing and/or multi-threaded operation with other processors incomputer system 500. Computer system 500 may also include input/output(I/O) devices such as a keyboard 508, a mouse 510, and a display 512.

Computer system 500 may include functionality to execute variouscomponents of the present embodiments. In particular, computer system500 may include an operating system (not shown) that coordinates the useof hardware and software resources on computer system 500, as well asone or more applications that perform specialized tasks for the user. Toperform tasks for the user, applications may obtain the use of hardwareresources on computer system 500 from the operating system, as well asinteract with the user through a hardware and/or software frameworkprovided by the operating system.

In one or more embodiments, computer system 500 provides a system forrendering a view component in a user interface of an application on anelectronic device. The system may include a styling component thatgenerates, from content describing a view for display in the userinterface, a styling path for the view component that includes aposition of the view component in a content hierarchy of the view. Next,the styling component may select a style context for the view componentfrom a collection of style contexts by matching at least a subset of thestyling path to an identifier for the style context. The stylingcomponent may then use the style context to render the view component inthe view.

In addition, one or more components of computer system 500 may beremotely located and connected to the other components over a network.Portions of the present embodiments (e.g., rendering apparatus,processing apparatus, orchestrator, rendering components, server, etc.)may also be located on different nodes of a distributed system thatimplements the embodiments. For example, the present embodiments may beimplemented using a cloud computing system that manages the rendering ofplatform-independent content by a set of platform-specific renderingcomponents on a set of remote electronic devices.

The data structures and code described in this detailed description aretypically stored on a computer-readable storage medium, which may be anydevice or medium that can store code and/or data for use by a computersystem. The computer-readable storage medium includes, but is notlimited to, volatile memory, non-volatile memory, magnetic and opticalstorage devices such as disk drives, magnetic tape, CDs (compact discs),DVDs (digital versatile discs or digital video discs), or other mediacapable of storing code and/or data now known or later developed.

The methods and processes described in the detailed description sectioncan be embodied as code and/or data, which can be stored in acomputer-readable storage medium as described above. When a computersystem reads and executes the code and/or data stored on thecomputer-readable storage medium, the computer system performs themethods and processes embodied as data structures and code and storedwithin the computer-readable storage medium.

Furthermore, methods and processes described herein can be included inhardware modules or apparatus. These modules or apparatus may include,but are not limited to, an application-specific integrated circuit(ASIC) chip, a field-programmable gate array (FPGA), a dedicated orshared processor that executes a particular software module or a pieceof code at a particular time, and/or other programmable-logic devicesnow known or later developed. When the hardware modules or apparatus areactivated, they perform the methods and processes included within them.

The foregoing descriptions of various embodiments have been presentedonly for purposes of illustration and description. They are not intendedto be exhaustive or to limit the present invention to the formsdisclosed. Accordingly, many modifications and variations will beapparent to practitioners skilled in the art. Additionally, the abovedisclosure is not intended to limit the present invention.

What is claimed is:
 1. A method, comprising: obtaining platform agnosticdata describing a view of an application for display in a userinterface; generating, from the platform agnostic data, a styling pathstring that includes a set of content identifiers; determining that acollection of style contexts from the platform agnostic data does notinclude an exact match for the styling path string; generatingvariations of a styling path remainder by iteratively removing at leastone content identifier in a first round of iterations and a second roundof iterations; selecting a style context from the collection of stylecontexts for the view that matches a variation from the variations ofthe styling path remainder to an identifier for the style context; andrendering, based on the selected style context, the view in the userinterface of the application.
 2. The method of claim 1, wherein thefirst round of iterations includes: removing an identifier from a middleof the styling path string to generate a first variation of thevariations of the styling path remainder; and iteratively removing anidentifier from a middle of the first variation of the styling pathremainder to generate additional variations of the styling pathremainder.
 3. The method of claim 2, wherein the second round ofiterations includes: removing an identifier from a beginning of thestyling path string to generate a second variation of the styling pathremainder; and iteratively removing an identifier from a middle of thesecond variation of the styling path remainder to generate additionalvariations of the styling path remainder.
 4. The method of claim 2,wherein the second round of iterations includes recursively removing anidentifier from each variation of the styling path remainder until thestyling path remainder includes a single content identifier.
 5. Themethod of claim 1, wherein selecting the style context furthercomprises: matching the variation from the variations of the stylingpath remainder to a wildcard pattern.
 6. The method of claim 1, whereineach content identifier in the styling path string corresponds to a viewcomponent.
 7. The method of claim 1, wherein each style context includesa set of style attributes for the view.
 8. A system, comprising: aprocessor; and a memory storing instructions, which when executed by theprocessor perform a method comprising: obtaining platform agnostic datadescribing a view of an application for display in a user interface;generating, from the platform agnostic data, a styling path string thatincludes a set of content identifiers; determining that a collection ofstyle contexts from the platform agnostic data does not include an exactmatch for the styling path string; generating variations of a stylingpath remainder by iteratively removing at least one content identifierin a first round of iterations and a second round of iterations;selecting a style context from the collection of style contexts for theview that matches a variation from the variations of the styling pathremainder to an identifier for the style context; and rendering, basedon the selected style context, the view in the user interface of theapplication.
 9. The system of claim 8, wherein the first round ofiterations includes: removing an identifier from a middle of the stylingpath string to generate a first variation of the variations of thestyling path remainder; and iteratively removing an identifier from amiddle of the first variation of the styling path remainder to generateadditional variations of the styling path remainder.
 10. The system ofclaim 9, wherein the second round of iterations includes: removing anidentifier from a beginning of the styling path string to generate asecond variation of the styling path remainder; and iteratively removingan identifier from a middle of the second variation of the styling pathremainder to generate additional variations of the styling pathremainder.
 11. The system of claim 9, wherein the second round ofiterations includes recursively removing an identifier from eachvariation of the styling path remainder until the styling path remainderincludes a single content identifier.
 12. The system of claim 8, whereinselecting the style context further comprises: matching the variationfrom the variations of the styling path remainder to a wildcard pattern.13. The system of claim 8, wherein each content identifier in thestyling path string corresponds to a view component.
 14. The system ofclaim 8, wherein each style context includes a set of style attributesfor the view.
 15. A non-transitory computer readable storage mediumcomprising instructions, which when executed by a processor of acomputing device, cause the computing device to perform a methodcomprising: obtaining platform agnostic data describing a view of anapplication for display in a user interface; generating, from theplatform agnostic data, a styling path string that includes a set ofcontent identifiers; determining that a collection of style contextsfrom the platform agnostic data does not include an exact match for thestyling path string; generating variations of a styling path remainderby iteratively removing at least one content identifier in a first roundof iterations and a second round of iterations; selecting a stylecontext from the collection of style contexts for the view that matchesa variation from the variations of the styling path remainder to anidentifier for the style context; and rendering, based on the selectedstyle context, the view in the user interface of the application. 16.The non-transitory computer readable storage medium of claim 15, whereinthe first round of iterations includes: removing an identifier from amiddle of the styling path string to generate a first variation of thevariations of the styling path remainder; and iteratively removing anidentifier from a middle of the first variation of the styling pathremainder to generate additional variations of the styling pathremainder.
 17. The non-transitory computer readable storage medium ofclaim 16, wherein the second round of iterations includes: removing anidentifier from a beginning of the styling path string to generate asecond variation of the styling path remainder; and iteratively removingan identifier from a middle of the second variation of the styling pathremainder to generate additional variations of the styling pathremainder.
 18. The non-transitory computer readable storage medium ofclaim 16, wherein the second round of iterations includes recursivelyremoving an identifier from each variation of the styling path remainderuntil the styling path remainder includes a single content identifier.19. The non-transitory computer readable storage medium of claim 15,wherein selecting the style context further comprises: matching thevariation from the variations of the styling path remainder to awildcard pattern.
 20. The non-transitory computer readable storagemedium of claim 15, wherein each content identifier in the styling pathstring corresponds to a view component.